Technique for providing interoperability between different protocol domains

ABSTRACT

The disclosure relates to a technique for providing interoperability between an Internet protocol multimedia subsystem (IMS) domain and a non-IMS domain. A method implementation of this technique comprises the steps of receiving on a service layer a service invocation message from a non-IMS domain, analyzing the message to identify the message as a request to invoke a service within the IMS domain, converting non-IMS session control protocol elements contained in the message into IMS session control related protocol elements, and generating an outgoing IMS message to establish an IMS control session.

FIELD OF THE INVENTION

The present invention relates to a technique for providinginteroperability between different protocol domains. The technique isparticularly adapted for use in connection with the Internet protocolmultimedia subsystem (IMS) domain. In this regard, the present inventionis designed to provide interoperability with an IMS session controlprotocol.

BACKGROUND OF THE INVENTION

The IMS is a standardised next generation network (NGN) architecture fornetwork operators providing mobile and fixed multi-media services. Ituses a 3^(rd) Generation Partnership Project (3GPP) standardisedimplementation of SIP and runs over the standard Internet protocol (IP).Existing telephone systems (both packet-switched and circuit-switched)are supported also. IMS uses open standard IP protocols as defined bythe Internet Engineering Task Force (IETF). In this way, a multimediasession for example between two IMS users, between an IMS user and auser on the Internet, or between two users on the Internet can beestablished using exactly the same protocols. IMS merges the Internetand the cellular worlds by using cellular technologies to provideubiquitous access and Internet technologies to provide appealingservices.

The IMS comprises three main components: the serving call sessioncontrol function (S-CSCF) on a control layer, and the home subscriberserver (HSS) as well as a session initiation protocol (SIP) applicationserver (AS) on an application layer.

The SIP protocol is a core control technology of IMS. It is used forcontrolling multimedia sessions combining for example voice and datastreams. Essentially, SIP is a text-based protocol for communicationsessions between parties. In particular, SIP is used for theestablishment, control and finalization of communication sessionsbetween network-based applications and also for the control of mediachannels between those applications. After a session is established,other protocols can be used for communication between applications.Thus, the major functions of SIP are session control, addressing andmobility management on service level.

IMS provides a lot of common functions used by mobile networks, such asAAA (authentication, authorization, and accounting), charging, accesscontrol, and HSS (i.e. user profile databases). These functions of IMSare meant to be used by the converged applications in a uniform way, sothat there is no need to have separate mechanisms applied for example tovoice and to data communications.

In parallel to the IMS domain, the extensible Markup Language (XML) WebServices (WS) concept has been developed. XML WS are a relatively newtechnology for the creation of distributed, highly interoperablesystems. XML WS are based on XML-based standards, like Simple ObjectAccess Protocol (SOAP), Web Service Definition Language (WSDL) andUniversal Description, Discovery and Integration (UDDI). Web Servicesare cross-platform interoperable, and programming language independent.They have become a popular means of development and system integrationof enterprise systems and network applications. Due to their flexibilityand a design that is more aligned with IT networks, Web Services basedarchitectures, e.g. Service Oriented Architectures (SOAs), are emergingquickly and are likely to be adopted in mobile communication networkdesign.

Most Web Services are stateless, which means that each invocation of theWeb Service should contain all the information it needs to process arequest, since the processing depends only on this data. This designgreatly simplifies implementation of WS. Recently, however, manyresearchers and practitioners in the WS area have realized that there isalso a need for stateful Web Services. Such stateful services areparticularly important for transactions involving several serviceinvocations. They are equally important where a correlation betweenmessages is required, e.g. electronic banking, and booking of tickets.Several WS specifications that address these issues, e.g. WS-Context,WS-Addressing and WS-Resource Framework, have been submitted tostandardization, but most of these simply complement WS SOAP invocationheaders through session information headers.

The IMS architecture defines that all incoming service invocations becarried out over SIP sessions. The IMS nodes, e.g. CSCF-I and theCSCF-P, are SIP servers that handle incoming SIP messages. However, eventoday many non-SIP based services exist in the operator domain and theseservices often use non-SIP protocols and technologies (e.g. WebServices, but also J2EE, NET, etc.).

Providing access for external users to services, in particular non-SIPservices, in the IMS domain is generally not possible because externalthird-party non-SIP service consumer applications are typically unawareof the fact that the invoked service is located inside the IMS domain,and such external consumer applications typically do not support SIP.Hence, a non-SIP service consumer is unable to access the service inquestion inside the IMS domain, which greatly reduces the availabilityand therefore the value of the service.

SIP and WS address similar problems, but each has its own solutions tosession management. In other words, the approaches used for sessionmanagement by SIP and WS are independent from each other. As a result,Web Services deployed inside the IMS domain require their ownIMS-incompatible WS infrastructure, including authentication,accounting, charging and other IMS functionality. Further, WSinvocations are executed based on URLs (unique resource locators) thatrequire a precise knowledge of the service's current network address(e.g. IP number, DNS name, etc.). This means that users cannot invokeservices hosted on mobile platforms (e.g. mobile terminals, and networknodes that regularly change their URL) until their current URL is known.

However, Web Service SOAP invocation headers are complemented throughsession information headers. This can lead to large SOAP messagescompared to the size of the payload. Such headers are sent with eachSOAP message and thus consume more bandwidth than session-less WebServices. Increased traffic can be a special issue in the over-the-airmobile environments, where it could introduce a higher network load andlead to bigger latencies. While compression schemes to compress anddecompress SOAP messages may be employed to address this issue, thesehave been shown to be very resource intensive and time consuming, evenwith high-end mobile terminals.

Accordingly, there is a need for a technique for providing increasedinteroperability between services located within the IMS domain andclient components situated outside the IMS domain.

SUMMARY OF THE INVENTION

According to one aspect, the present invention provides a method ofproviding interoperability between an Internet protocol multimediasubsystem (IMS) domain and a non-IMS domain, wherein the methodcomprises the steps of receiving on a service layer a service invocationmessage from a non-IMS domain, analyzing the message to identify themessage as a request to invoke a service within the IMS domain,converting on a session control layer non-IMS session control protocolelements related to the message into IMS session control relatedprotocol elements, and sending one or more messages towards the IMSdomain to provide an IMS control session in the IMS domain based on theIMS session control related protocol elements.

In one example, the conversion step may be based on a mapping schemethat associates individual non-IMS session control protocol elementswith individual IMS session control related protocol elements. Protocolelements include protocol-specific message types (such as serviceinvocation messages), message portions (such as headers), and messagefields (such as header fields specifying particular addresses).

The method may also include the step of forwarding on the service layerthe service invocation message using the IMS control session. The methodmay further include the steps of receiving at least one further messagefrom the non-IMS domain related to the invoked service within the IMSdomain, and forwarding on the service layer the service message usingthe IMS control session. A mapping scheme may also be used here toassociate a particular service requestor (e.g. an application or anetwork component outside the IMS domain) with one or more requested(and/or ongoing) sessions inside the IMS domain.

The method of the invention may further include the steps of receiving amessage from the IMS domain during the session, converting IMS sessioncontrol related protocol elements related to the message from the IMSdomain into non-IMS session control protocol elements, generating anon-IMS message based on the non-IMS session control protocol elements,and sending the non-IMS message during the session towards the non-IMSdomain.

In one variation of the invention, the service within the IMS domain isan IMS protocol based service. For example, the service in the IMSdomain could be an IMS support function that may include one or more ofthe following functions: authentication, authorization, accounting (e.g.AAA), charging, access control, and HSS. Here, the IMS session controlprotocol may be the DIAMETER protocol that provides for exampleaccounting information for the service. The service itself may beprovided from within or from outside the IMS domain.

In another variation, the service in the IMS domain is a non-IMSprotocol-based application (e.g. a programmatically accessible servicesuch as a Web Services based application operated from within the IMSdomain). Here, the IMS session control protocol may be SIP that controlsthe provision (e.g. establishment and/or general management) of the IMSservice session.

The non-IMS session control protocol elements preferably compriseheaders of a non-IMS session control protocol, and the IMS sessioncontrol related protocol elements preferably comprise headers such asSIP headers. By way of example, the non-IMS protocol based service mayemploy a Markup Language (ML) based messaging protocol, such as XML WebServices.

Preferably, the method further includes the steps of analyzing themessage received from the non-IMS domain and/or from the IMS domain,determining a state of the session with the service in the IMS domainbased on the analyzed message, and storing the state of the session.Storing the state of a particular session facilitates the mappingbetween individual services within the IMS domain and the individualsessions (that potentially stretch into the non-IMS domain).

According to a further aspect, it may be checked (e.g. in response toreceipt of a message from the non-IMS domain) whether a session with aservice in the IMS domain is ongoing, and, if there is no ongoingsession, a new session may be established under an IMS session controlprotocol such as SIP.

Preferably, non-IMS messages are authenticated prior to establishing thecontrol session in the IMS domain. Authentication may be performed byanalyzing an address specified in a non-IMS message.

In one variation, the method further includes the steps of employing auniform addressing scheme using SIP addressing for the invocation offixed and/or mobile services. In this way, when the service to beinvoked resides on a mobile platform inside the IMS domain, the methodmay further comprise the step of defining a SIP unique resourceidentifier (URI) for dynamic invocation of the service in the IMSdomain, regardless of a current unique resource locator (URL) for themobile platform.

Thus, a further concept which may operate independently of the abovedescribed protocol element conversion is a method of addressing andinvoking fixed and mobile services using a uniform addressing scheme bymeans of SIP addressing, comprising the steps of defining use of a SIPURI for dynamic invocation of mobile services regardless of theircurrent URL (e.g. by defining an extension for WS-Addressing) and/ordefining the fixed addressing of services using a SIP URL. Instead ofSIP, other IMS session control protocols could be used as well foraddressing and identifying purposes.

According to another aspect, the present invention provides a computerprogram product comprising program code portions for performing thesteps of the method is when the computer program product is run on oneor more computers or computer systems. The computer program product maybe stored on a computer readable recording medium.

According to a further aspect, the present invention provides a computerprocessor and a memory coupled to the processor, wherein the memory isencoded with one or more programs that may perform steps for providinginteroperability between an IMS domain and a non-IMS domain according tomethod of the invention described above.

According to a still further aspect of the invention, there is provideda mapping device for providing interoperability between an Internetprotocol multimedia subsystem (IMS) domain and a non-IMS domain, themapping device comprising an analyzing unit to analyze incoming serviceinvocation messages received on a service layer from the non-IMS domain,to identify whether one of the service invocation messages is aninvocation of a service within the IMS domain, a conversion unit toconvert on a session control layer non-IMS session control protocolelements related to the one of the messages into IMS session controlrelated protocol elements, and a messaging unit to generate one ore moremessage to provide an IMS control session in the IMS domain based on theIMS session control related protocol elements.

The mapping device of the invention may be implemented as a gatewaybetween the IMS domain and the non-IMS domain. Alternatively, themapping device may be integrated in a protocol stack of a networkcomponent in the non-IMS domain. Other implementations may be used aswell.

BRIEF DESCRIPTION OF THE DRAWINGS

Particular embodiments of the present invention will now be describedwith reference to the accompanying drawings, in which like referencenumerals identify like features, and in which:

FIG. 1 is a schematic flowchart illustrating a method embodimentaccording to the present invention;

FIG. 2 is a schematic illustration of a mapping device embodimentaccording to the present invention operating to convert messagesreceived from the non-IMS domain;

FIG. 3 is a schematic illustration of a mapping device embodimentaccording to the present invention operating to convert messagesreceived from the IMS domain;

FIG. 4 illustrates an embodiment according to the present inventionembodied as a SOAP over SIP gateway for accessing Web Services in theIMS domain;

FIG. 5 illustrates an embodiment according to the present inventionembodied as a design-time SOAP to SIP session mapping for accessing WebServices in the IMS domain;

FIG. 6 illustrates an embodiment according to the present inventionembodied as a SOAP over SIP mapping for transparently accessing IMSfacilities for user/service management; and

FIG. 7 illustrates an embodiment according to the invention using SIPURIs to implement addressing of mobile services.

DETAILED DESCRIPTION OF THE INVENTION

In the following description, for purposes of explanation and notlimitation, specific details are set forth, such as particular sequencesof steps, protocol standards and various configurations of devices inorder to provide a thorough understanding of the present invention. Itwill be understood that the present invention may be practiced in otherembodiments that depart from these specific details.

Moreover, those skilled in the art will appreciate that the functionsexplained herein below may be implemented using software functioning inconjunction with a programmed microprocessor or general purposecomputer, and/or using an application specific integrated circuit(ASIC).

The technique for providing interoperability between different protocoldomains according the present invention will firstly be described withreference to FIGS. 1 and 2. FIG. 1 schematically illustrates a methodembodiment for providing interoperability between an IMS domain and anon IMS domain. Correspondingly, FIG. 2 schematically illustrates anembodiment of a mapping device 100, which operates to provide thisinteroperability between the IMS domain and the non-IMS domain.

With reference to both of FIGS. 1 and 2, the first step S1 of the methodinvolves receiving on a service (or application) layer a serviceinvocation message 101 from the non-IMS domain. This message 101 isreceived by the mapping device 100. The second step S2 of the methodinvolves analyzing the message received from the non-IMS domain. Inother words, the message 101 received by the mapping device 100undergoes analysis in an analyzing unit 102 of the mapping device. Thethird step S3 involves identifying the service invocation messagereceived from the non-IMS domain as a request to invoke a service withinthe IMS domain (compared, for example, to a service that is to beprovided from outside the IMS domain) This service may, for example, bean IMS support function, such as AAA or HSS, or a non-IMS serviceprovided from inside the IMS domain. The step of identifying the natureof the message 101 received by the mapping device 100 is typicallycarried out by the analyzing unit 102.

After the message 101 received from the non-IMS domain has beenidentified as an invocation of a service within the IMS domain, themethod includes the further step S4 of converting non-IMS sessioncontrol protocol elements related to the service invocation message intoIMS session control related protocol elements. In this regard, themethod of the invention provides a conversion or mapping of, forexample, non-IMS session control protocol headers into protocol headersof an IMS session control protocol, such as SIP. To this end, themapping device 100 includes a conversion unit 104 to undertake thisconversion of non-IMS protocol elements into IMS protocol elements.

The conversion can be supported through information contained in fieldsof incoming invocation messages. Such information can be gathered from:the IP-address of the sender, possibly also his DNS address, servicespecific fields such as the Web Service (e.g. SOAP, WS-Context) messagesand authentication information in the form of credentials included inthe message.

For example in the case of CORBA, the request_id and service_contextsfields can be used to derive information related to the transaction orsession, whereas fields such as requesting_principal and operation canbe used to derive information related to the SIP From and To fields. Ingeneral this type of information can be converted by a mapping to SIPsession establishment fields such as From, To, Allow, Supported andContact.

The method then includes the further step S5 of generating an outgoingmessage 107 in context with providing an IMS control session (e.g.establishing a control session or controlling an established controlsession) in the IMS domain based on the IMS session control relatedprotocol elements. Establishment of the session can involve the exchangeof several messages between the mapping device 100 and the service.Consequently, the mapping device may take the role of a communicationpartner during session establishment in the IMS domain.

Naturally, in addition to, for example, an initial message from thenon-IMS domain invoking the service within the IMS domain, one or morefurther messages 101 may additionally be received from the non-IMSdomain. In this respect, the messaging unit 106 of the mapping device100 is adapted to generate a corresponding outgoing IMS message tocontrol the session once it has been established.

Similarly, with reference now to FIG. 3, it may also be the case that amessage 107 is received from the IMS domain during the session that hasbeen established for the invoked service. A message 107 received fromthe IMS domain is handled by the mapping device 100 in a reciprocalmanner. Specifically, IMS session control related protocol elements,such as SIP headers, contained in that message may be converted by theconversion unit 104 into non-IMS session control protocol elements, anda corresponding non-IMS message may be generated by the messaging unit106. The mapping device 100 then sends this non-IMS message 101 to thenon-IMS domain in the course of the established session or thereafter.It will be appreciated that, in FIGS. 2 and 3, the reference numeral 101identifies a non-IMS and the reference numeral 107 identifies an IMSmessage.

The following embodiments provide generic approaches for enablinginteroperability between session-oriented non-SIP and SIP services.Furthermore, the embodiments also enable the provision of sessionfunctionality to non-session oriented service technologies (e.g. WebServices).

The mapping between non-SIP services and SIP sessions is accomplished byan entity (e.g. the mapping device 100 shown in FIGS. 2 and 3 or adifferent device) that stores the state of the particular session byparsing incoming messages (possibly in a number of different protocols).This knowledge is then used to generate appropriate outgoing messages(again possibly in a number of possible different protocols).

Non-SIP applications (from outside the IMS domain) that are not sessionbased and invoke services deployed within the IMS domain are not awareof SIP and, therefore, are not able to establish and maintain sessionsas required by IMS. For this reason, the implementation of the sessionmapping device takes care of initiation and management of sessions forthe applications in question, as required by the session-aware part ofthe transaction. This may require that all messages between the invokerand the invoked service be routed through the mapping device.

To achieve this, the operator can route all incoming traffic related topublicly available IMS services via the mapping device (e.g. on the IPor higher levels). For example, services in the IMS domain could beexposed via a URL or any other addressing mechanism hosted on themapping device. The operator may publishes this URL to external partiesfor addressing purposes.

For the sake of clarity, the embodiments used to illustrate thetechnical approach assume that the application server hosting exemplarynon-SIP services within the IMS domain contains both SIP and non-SIPstacks (e.g. WS, J2EE, CORBA, etc.) appropriate to the service beinginvoked. Even though other possible setups may involve differentprotocol stacks deployed on different configurations of nodes, thegeneral technical approach remains the same.

In the following, an embodiment of a session mapping mechanism will bedescribed with reference to a non-SIP application A (running for exampleon a WS capable user terminal located outside the IMS domain) invoking aservice B within the IMS domain. The non-SIP application thus acts as aclient with respect to IMS service B.

Session mapping can be accomplished with the following steps:

-   -   1. Incoming requests from non-SIP applications can be        authenticated based on a number of mechanisms which are        described below in more detail.    -   2. Based on the authentication of the non-SIP application A        invoking the IMS service B, the mapping device 100 checks        whether it already has knowledge of an ongoing service layer        transaction (corresponding to a particular session on the        session control layer in the IMS domain) between non-SIP        application A and IMS service B. To this end, a mapping table        may be consulted that may list a plurality of previously        established sessions for the non-SIP application A and/or any        other non-SIP applications A′.    -   3. If there is no ongoing transaction between non-SIP        application A and IMS service B, a new SIP session is        initialized. Here, the mapping device 100 plays the role of the        communication partner in the SIP session established with IMS        service B.        -   a. In case non-SIP application A is not session aware, the            device 100 establishes a new session without taking the            capabilities of non-SIP application A into further            consideration.        -   b. In case non-SIP application A is session aware, the            device 100 will establish the new session according to the            session capabilities of non-SIP application A (e.g.            WS-Context, WS-Addressing Headers, etc.). The following            first example illustrates the service invocation created by            the WS client A using the WS-Context specification for WS            session management. The second example illustrates how the            mapping device 100 establishes a new SIP session with IMS            service B, using the session information gathered from            mapping of the SOAP message intercepted by mapping device            100. This setup implies that the service B contains both SIP            and WS stacks. Other possible setups could involve different            protocol stacks deployed on different nodes.

An example of an XML-based service invocation message specifying aWS-Context session is given below:

<soap:Envelope xmlns:soap=″http://www.w3.org/2002/06/soap-envelope″><soap:Header> <contextxmlns=″http://docs.oasis-open.org/wscaf/2004/09/wsctx″ timeout=″100″xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”xmlns:soapbind=http://schemas.xmlsoap.org/wsdl/soap/soap:mustUnderstand=″1″> <context-identifier>http://services.operator.com/wscaf/2004/09/wsctx/abcdef:012345</context-identifier> <type>http://services.operator.com/wscaf/2004/09/wsctx/context/mmservice</type> </context> </soap:Header> <soap:Body> <!-- Application Payload--> </soap:Body> </soap:Envelope>

The mapping device 100 converts the non-SIP elements included in theabove service invocation message in a SIP session establishment messagespecifying session information from the WS-Context session as follows:

-   INVITE sips:service1@operator.com SIP/2.0-   Via: SIP/2.0/TLS server.operator.com:5061;branch=z9hG4bK74bf9-   Max-Forwards: 70-   From: SESSION1 <sips:sipsoapgw@operator.com>;tag=1234567-   To: SIPAS <sips:service1@operator.com>-   Call-ID: 12345601@operator.com-   CSeq: 1 INVITE-   Contact: <sips:sipsoapgw@operator.com>-   Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY-   Supported: replaces-   Content-Type: application/sdp-   Content-Length: . . .-   v=0-   o=servicebroker 2890844526 2890842807 IN IP4 asb.operator.com-   s=Conference Service-   t=0 0-   m=audio 5004 RTP/AVP 0-   c=IN IP4 131.160.1.112-   a=rtpmap:0 PCMU/8000-   m=message 49172 IMTP/TCP application/soap+xml-   c=IN IP4 asb.operator.com-   a=direction:both-   a=wsdl:http://schemas.operator.com/conferencecontrol.wsdl-   a=wscafcontextidentifier:http://services.operator.com/wscaf/2004/09/wsctx/abcdef:012345-   a=wscaftype:http://services.operator.com/wscaf/2004/09/wsctx/context/mmservice    -   4. In the event of an existing transaction, its status is        updated based on the processed message(s).    -   5. SOAP elements used for carrying session information are        converted to SIP headers and vice versa.

Transactions already mapped to SIP sessions can avoid re-sending WSsession-related information in the SOAP messages that was alreadynegotiated during SIP session initiation. The following examplesillustrate how based on an established SIP session (as described in step3b) the information related to the WS-Context session for WS serviceinvocation can be optimized through avoiding repetition of theWS-Context related information in the SOAP header.

-   -   a) An Example of service invocation specifying a WS-Context        session:

<soap:Envelope xmlns:soap=″http://www.w3.org/2002/06/soap-envelope″><soap:Header> <contextxmlns=″http://docs.oasis-open.org/wscaf/2004/09/wsctx″ timeout=″100″xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”xmlns:soapbind=http://schemas.xmlsoap.org/wsdl/soap/soap:mustUnderstand=″1″> <context-identifier>http://services.operator.com/wscaf/2004/09/wsctx/abcdef:012345</context-identifier> <type>http://services.operator.com/wscaf/2004/09/wsctx/context/mmservice</type> </context> </soap:Header> <soap:Body> <!-- Application PayloadMMService specific payload --> </soap:Body> </soap:Envelope>

-   -   b) An example of optimized service invocation without explicit        specification of a WS-Context session:

<soap:Envelope xmlns:soap=“http://www.w3.org/2002/06/soap-envelope”><soap:Header> </soap:Header> <soap:Body> <!-- Application PayloadMMService specific payload --> </soap:Body> </soap:Envelope>

-   -   6. The SIP messages thus generate are forwarded to IMS service        B.

Before authentication based on a SOAP envelope as described in step 3 ofthe above algorithm can be applied, an agreement between the serviceconsumer and the service provider has to be reached on how to providerequired credentials. Such credentials can be exchanged using thefollowing protocol:

-   -   1. The operator, as service provider, defines a format for the        exchange of credentials including various types of data        describing the application and authenticating the user (e.g.        login name, password, application name, etc.). Such a format can        be implemented by various means, e.g. by extending the WSDL        description of the given service to include appropriate        parameters, or to extend the header of the SOAP messages again        with appropriate header parameters.    -   2. Applications seeking authentication need to implement an        authentication scheme based on the schema provided by the        operator as described in step 1.        -   a. Credentials for authenticating subscribers of the            operator are generated based on common secrets known to both            the operator and the application (e.g. the id-system of the            user, terminal data, etc.).        -   b. Credentials for authenticating non-subscribers need to be            agreed upon in advance. This can happen through registration            in appropriate sites provided by the operator.

In the following, an embodiment of an authentication mechanism that canbe used in combination with the above session mapping mechanism will bedescribed. As input, the mechanism receives incoming invocation requestmessages from non-SIP applications running e.g. on terminals outside theIMS domain. The output will be the authentication status of the non-SIPapplications.

-   -   1. Analyze the IP address of the incoming request        -   a. Requests originating from addresses within the trusted            domain (from the operator itself or from other trusted            networks) are further processed in step 2.        -   b. Requests originating from outside the trusted domain are            further processed in step 4.    -   2. IF the IP address is the address of a known and trusted node        that adds authentication credentials to the request (e.g. a WAP        gateway)        -   a. THEN IF embedded credentials are available (e.g. in the            case of a WAP gateway check for special HTTP header inserted            by the WAP-gateway)            -   i THEN Analyse credentials (e.g. extract MSISDN number)            -   ii ELSE goto step 3        -   b. ELSE goto step 3    -   3. Analyze request (e.g. SOAP envelope) and check the        availability of authentication credentials (e.g. inside SOAP        header/body)        -   a. IF credentials are available then remove authentication            data required by the mapping device from the request in            order to comply with the original service API. Proceed with            further authentication based on this data in step 5.            -   The following examples illustrate how the required                credentials for establishing the IMS session are                extracted from the incoming extended SOAP message                thereby producing a non-extended SOAP message.

An example of SOAP request extended with authentication credentials isgiven below:

<soap:Envelope xmlns:soap=http://www.w3.org/2002/06/soap-envelopexmlns:auth = “http://liberty.org”> <soap:Header> <auth:credential1name=”user1”/> <auth:credential2:password=”secret”/> </soap:Header><soap:Body> <!-- Application Payload MMService specific payload --></soap:Body> </soap:Envelope>

An example of SOAP request without authentication credentials is givenbelow:

<soap:Envelope xmlns:soap=“http://www.w3.org/2002/06/soap-envelope”><soap:Header> </soap:Header> <soap:Body> <!-- Application PayloadMMService specific payload --> </soap:Body> </soap:Envelope>

-   -   b. ELSE goto step 4    -   4. Use address properties of the incoming packet (e.g. IP        address, DNS address, MAC address, etc.) to implicitly determine        the id-system of the user and create appropriate temporary        credentials. It should be noted that this identification is not        as precise and secure as the identification enabled through        previous steps. The lack of precision can be attributed e.g. to        lack of unique mapping between IP addresses and applications.    -   5. Convert credentials to IMS format, use them to authenticate        the application

In the following, some embodiments of mapping devices 100 will bediscussed in more detail.

According to one embodiment shown in FIG. 4, the mapping device 100 isimplemented as a gateway node located between the IMS domain 10 andclients 20 situated in the non-IMS domain (e.g. SOAP clients 20 usingWeb Services). FIG. 4 illustrates a non-SIP to SIP run-time sessionmapping for accessing non-SIP operator-controlled services deployedinside the IMS domain 10.

The Service Description Protocol (SDP) can be used to describe differenttypes of SIP services. Each SIP session initiation can contain an SDPdescription. One possibility therefore would be to define SDPdescriptions for establishing sessions of a specific type ascorresponding to specific non-IMS service invocations and sessionestablishment/management technology. Session mapping/conversion can thusalso be enabled by mapping certain fields of incoming serviceinvocations to their corresponding fields in the SDP description. Inthis case specific types of non-IMS service invocations (e.g. CORBAservices, J2EE services, Java RMI services, NET services and naturallypure SOAP Services) would be mapped to specific pre-defined SDPdescriptions for these technologies.

The session mapping may be implemented using a table listing thecurrently ongoing sessions. In the table, each ongoing session may beassociated with particular parameters that allow the mapping device 100,upon a receipt of a service layer message from the clients 20, toidentify whether or not the message relates to an ongoing session withinthe IMS domain 10. In principle, an individual client 20 may beassociated with the plurality of individual sessions involving one andthe same service or different services within the IMS domain 10.

As shown in FIG. 4, a service invocation message is received by themapping device 100 on a service layer (SOAP over HTTP) and recognized asinvoking a service within the IMS domain 10. Then, on a session controllayer (“SIP layer”), a protocol element conversion takes place withinthe mapping device 100 in context with providing an IMS control session(“SIP-controlled session”) for the service to be invoked. The IMScontrol session is then used as vehicle for communication between theclient 20 and the requested service within the IMS domain 20.-

In the scenario of FIG. 4, the mapping device 100 is completelytransparent to the invoking SOAP clients 20 (i.e., the clients 20 neednot have any knowledge of the presence and function of the mappingdevice 100). This is advantageous because it allows usage by standard(non-modified) clients 20 in a non-IMS domain.

The mapping device 100 may also be implemented on the side of thenon-IMS domain, e.g. within the client 20 by modifying the clientprotocol stacks (i.e. J2EE, WS SOAP stack, etc.). This is depicted inFIG. 5 using Web Services as an example.

FIG. 5 illustrates a non-SIP to SIP run-time session mapping foraccessing non-SIP operator-controlled services deployed inside the IMSdomain 10. In this scenario, the mapping device 100 is integrated in theclient protocol stack of the client 20 in the non-IMS domain. Thissolution is particularly advantageous because it does not require thedeployment of additional network nodes (e.g. of gateways as in theembodiment shown in FIG. 4).

Given the lack of widespread IMS enabled clients (e.g. user terminalssuch as mobile telephones) in the market, such a modified stack could bedirectly implemented in the first generation of such clients. This is anadvantage as it eliminates update-related costs compared to typicaldeployment scenarios requiring existing clients to be updated withadditional functionality.

The implementation of the mapping device 100 as a gateway is usuallyused for transparent access to the operator-controlled services insidethe IMS domain 10. A special use-case for the gateway-based solutioncould be the situation where two non-IMS components 20, 30 communicatewith each other through such a gateway 100 to be able to utilize IMSservices in the form of support functions provided by the IMS domain 10(such as AAA, HSS, etc., using the DIAMETER protocol). This scenario isshown in FIG. 6 and is particularly interesting for third-partyservice-providers, as they consider the operator to be a reliable andtrustworthy mediator. The operator, in turn, may also benefit as it cancharge for providing this functionality.

The scenario shown in FIG. 6 may require that a service provider 30 in anon-IMS domain has an appropriate business agreement with the IMSoperator and has deployed his service in a way that it is registered andaccessible via the mapping device gateway 100. Alternatively, a client20 in a non-IMS domain may also be registered with the operator. Thisallows the client 20 to take advantage of operator-provided SIPauthentication and authorization mechanisms to identify itself towardsthe third-party service provider 30.

With reference to FIG. 7, an embodiment of a SIP-based uniformaddressing and service invocation scheme that can be used in combinationwith the above embodiments will be described.

Instead of using the HTTP (HyperText Transfer Protocol) URL, the logicalSIP URIs (and eventually SIP URLs) are used for the uniform addressingscheme and for mobile service invocations. The access to the service viaURI allows for service mobility by providing a transparent access to theservice regardless of its current URL. This allows for addressing of IMSservices deployed on mobile devices not having a fixed attachment to thenetwork and consequently not having a fixed URL.

The scenario shown in FIG. 7 involves two major steps, namely

-   -   a. defining the use of a SIP URI for dynamic invocation of        mobile IMS services regardless of their current URL. (Possibly        by defining an extension for WS-Addressing.)    -   b. defining the fixed addressing of services using a SIP URL

As has been shown in the above embodiments, the interoperability betweenthe IMS and any other domain can be increased by establishing a mappingbetween a WS session/service and (one or multiple) SIP sessions. In thiscontext, the SOAP elements used for carrying the session information canbe converted into SIP headers and vice versa. Re-sending of the WSsession-related information in the SOAP messages inside IMS/SIP networkscan be avoided if the SIP session has already been provided with it.

The techniques can be performed by a SIP-to-non-SIP (e.g. SIP-SOAP)gateway that transparently maps between e.g. non-SIP services and SIPsessions and can be used without adaptation of the client application.Alternatively, the techniques are performed in the above embodiments byextending the WS stack/SIP stack to enhance applications allowing themto transparently map between WS sessions and SIP sessions withoutadditional infrastructure components in the network.

Thus, the embodiments provide WS invocation within an IMS domain ornetwork. They allow the use of existing, more efficient SIP-basedsession management mechanisms for WS session management and provide abetter interoperability and integration between the IMS system andinfrastructure and the Web Services deployed inside the IMS domain.Furthermore, the embodiments make it possible to use standard IMSmechanisms for AAA, charging, etc also for invocations and control ofservices such as Web Services outside IMS domain. In so doing, theembodiments allow for a seamless integration of Web Services into IMSsystems. Developers do not need to explicitly support the IMS/SIPprotocols and APIs. All this may be done transparently or by theextensions of WS and/or SIP stacks.

Furthermore, the embodiments enable a reduction in the amount of trafficrequired for transmission of session information by e.g. Web Servicesinside IMS networks. The embodiments also provide Web Services withmobility by allowing invocation using its URI that may be different fromits URL. This allows the service to change its execution platform (andtherefore its URL) while still being addressable under the same URI. Inthis regard, the routing of service invocation calls may be handled by aSIP registry (i.e. a CSCF node in the IMS domain) that is aware of thecurrent position of every user and redirects service invocation callsusing the SIP URI to the currently correct SIP URL.

It should be noted that the approaches set forth above can be used notonly for mapping of Web Services sessions to SIP sessions. In principle,the invention can be used for mapping of any external Remote ProcedureCall (RPC) protocol having the concept of sessions to any IMS internalprotocol suitable for the required needs. These may include, forexample, CORBA, Java RMI, and other proprietary protocols.

While the present invention has been described with respect toparticular embodiments, those skilled in the art will recognize that thepresent invention is not limited to the specific embodiments describedand illustrated herein. Therefore, while the present invention has beendescribed in relation to its preferred embodiments, it is to beunderstood that this disclosure is only illustrative. Accordingly, it isintended that the invention be limited only by the scope of the claimsappended hereto.

1-21. (canceled)
 22. A method of providing interoperability between anInternet protocol multimedia subsystem (IMS) domain and a non-IMSdomain, comprising the steps of: receiving on a service layer a serviceinvocation message from the non-IMS domain; analyzing the message toidentify the message as a request to invoke a service within the IMSdomain; converting, on a session control layer, non-IMS session controlprotocol elements related to the message into IMS session controlrelated protocol elements; sending one or more messages towards the IMSdomain to provide an IMS control session in the IMS domain based on theIMS session control related protocol elements; and forwarding on theservice layer the service invocation message using the IMS controlsession.
 23. The method of claim 22, further comprising the steps of:receiving a further message from the non-IMS domain related to theservice invoked within the IMS domain; and forwarding on the servicelayer the service message using the IMS control session.
 24. The methodof claim 22, further comprising the steps of: receiving a message fromthe IMS domain during the session; converting IMS session controlprotocol elements related to the message from the IMS domain intonon-IMS session control protocol elements; generating a non-IMS messagebased on the non-IMS session control protocol elements; and sending thenon-IMS message to the non-IMS domain.
 25. The method of claim 24,wherein the non-IMS message is sent to the non-IMS domain during thesession.
 26. The method of claim 22, wherein the service in the IMSdomain is an IMS support function including authentication,authorization, accounting, charging, access control, or HSS.
 27. Themethod of claim 22, wherein the service in the IMS domain is a non-IMSprotocol based application.
 28. The method of claim 22, wherein the IMSsession control protocol elements comprise session initiation protocol(SIP) headers and the non-IMS session control protocol elements comprisenon-SIP headers.
 29. The method of claim 22, wherein the non-IMS domainemploys a protocol for exchanging Markup Language (ML) based messages.30. The method of claim 22, comprising the steps of: analyzing themessage received from the non-IMS domain or from the IMS domain;determining a state of the session with the service in the IMS domainbased on the analyzed message; and storing the state of the session. 31.The method of claim 22, comprising the steps of: checking whether asession with the service in the IMS domain is ongoing; and if there isno ongoing session, initializing a new session under the IMS sessioncontrol protocol.
 32. The method of claim 22, further comprising thestep of associating a service requestor with one or more requested orongoing sessions inside the IMS domain.
 33. The method of claim 32,wherein the service requestor is an application or a network componentoutside the IMS domain.
 34. The method of claim 22, comprising the stepo: authenticating the non-IMS message prior to establishing the controlsession in the IMS domain.
 35. The method of claim 34, wherein the stepof authenticating the non-IMS message comprises analyzing an addressspecified in the message.
 36. The method of claim 22, comprising thestep of employing a uniform addressing scheme using SIP addressing forthe invocation of fixed and/or mobile services.
 37. The method of claim22, wherein the service to be invoked resides on a mobile platforminside the IMS domain, the method comprising the step of defining a SIPunique resource identifier (URI) for dynamic invocation of the servicein the IMS domain, regardless of a current unique resource locator (URL)for the mobile platform.
 38. The method of claim 22, comprising the stepof defining a SIP unique resource locator (URL) for fixed addressing ofthe service in the IMS domain.
 39. A mapping device for providinginteroperability between a session initiation protocol (IMS) domain anda non-IMS domain, comprising: an analyzing unit to analyze incomingservice invocation messages received on a service layer from the non-IMSdomain, to identify whether one of the service invocation messages is aninvocation of a service within the IMS domain; a conversion unit toconvert on a session control layer non-IMS session control protocolelements related to one of the messages into IMS session control relatedprotocol elements; and a messaging unit to generate one or more messagesto provide an IMS control session in the IMS domain based on the IMSsession control related protocol elements; wherein the device is adaptedto forward on the service layer the service invocation message using theIMS control session.
 40. The mapping device of claim 39, wherein thedevice is implemented as a gateway between the IMS domain and thenon-IMS domain.
 41. The mapping device of claim 40, wherein the deviceis integrated in a protocol stack of a network component in the non-IMSdomain.
 42. A user terminal comprising a mapping device for providinginteroperability between a session initiation protocol (IMS) domain anda non-IMS domain, the mapping device comprising: an analyzing unit toanalyze incoming service invocation messages received on a service layerfrom the non-IMS domain, to identify whether one of the serviceinvocation messages is an invocation of a service within the IMS domain;a conversion unit to convert on a session control layer non-IMS sessioncontrol protocol elements related to one of the messages into IMSsession control related protocol elements, and a messaging unit togenerate one or more messages to provide an IMS control session in theIMS domain based on the IMS session control related protocol elements;wherein the device is adapted to forward on the service layer theservice invocation message using the IMS control session.
 43. The userterminal of claim 42, wherein the mapping device is implemented as agateway between the IMS domain and the non-IMS domain.
 44. The userterminal of claim 42, wherein the mapping device is integrated in aprotocol stack of a network component in the non-IMS domain.